The present invention relates in general to a computer editing system for editing files and information, and more particularly to a multi-threaded client and server editor capable of handling a plurality of editing activities simultaneously for improving performance.
Client/server computing defines an architecture for distributed processing between a client computer and a server computer. In a client/server computing model, instead of having the processing done entirely by a centralized system, e.g., a mainframe, a client computer shares some of the processing load. The client is an intelligent system able to perform its own processing and typically runs graphical user interfaces (GUIs) such as Windows programs and Web browsers. The client computer generally includes a desktop such as a PC and/or workstation. The server is typically a back-end system and includes a file server, print server, communications server, or any other system providing services. The server computer typically is a mainframe, or a midsize computer generally having more computing power than the client computers.
An example of client/server computing model is the World Wide Web (Web) on the Internet. A Web browser resident on a client computer communicates with a Web server which typically queries back-end systems and returns the results of the queries back to the client. The Web browser receives the results and presents the data in an appropriate form compatible for that particular client computer. In this Web client/server model, the applications are truly broken up into components, i.e., the Web browser and the Web server that run as services on different computers: a client computer and a server computer. An advantage of a client/server model is that multiple computers can perform functions in parallel simultaneously and cooperate to complete a task.
Although above described client/server computing is known widely, development work on a client/server platform, especially for mainframes is relatively new. Development work includes editing source files and/or information to perform a desired task. One conventional method of development on a client/server platform is to first retrieve the entire source file from a server or server library system maintaining the file by copying the entire file from the server system to the client; second, edit the file on the client; and third, copy the source back into the server or server library system. However, many disadvantages are associated with this conventional method. Typically, a client and server in a client/server model are connected remotely within one or more networks, such as a dial-up connection, LAN, WAN, and/or the Internet, and usually do not have a direct or dedicated line connection between them. When a client is connected to a server employing one or more of these network configurations, transferring data tends to take a large amount of time, often forcing a user at the client to wait before the user is able to begin a development or an editing session. This is especially true when downloading a large file. Moreover, if a downloading process terminates abnormally, e.g., due to a process failure without having completed the download, the user is forced to start the data transfer from the very beginning.
An alternative method, also commonly used by existing systems is to employ a terminal emulator such as the 3270 emulator on the client to edit the source file directly on the server remotely, without having the file transferred to the client. With this method, however, a user is limited to only those presentation abilities offered by a particular system and a terminal that is emulated, e.g., 3270 system.
Presently, the client/server development platform allows use of many advanced presentation abilities including the the graphics utilities of a workstation. Using a host emulator thus does not allow for the power and flexibility afforded by a client workstation. Therefore, it is highly desirable to be able to employ the state of the art modern workstation technology when developing or editing a source file located with the server. It is also highly desirable to have a client/server system which improves data transfer performance between the server and the client.
The present invention is directed to a high performance multi-threaded client/server editor and method for editing one or more remote files or information with improved performance. The files are typically stored on a storage media device accessible by a computer. The present invention includes an advantage of the speed, reliability and availability of a server and the powerful tools such as the presentation utilities of a client workstation. When an edit feature is invoked by a user at a client platform or workstation, the client component (client) of the high performance multi-threaded client/server editor of the present invention makes a request to the server component (server) to initiate downloading a file for editing. As the file is downloading from the server, the client displays the first page of the file to the user at a display terminal wherein the user is enabled to start editing the file even before the entire file is completely downloaded from the server. Other presentation methods for presenting the file via an appropriate presentation device to a user for editing may be utilized in another embodiment of the present invention.
When the user attempts to edit the portion of the file that has not yet been downloaded, the client sends the edit request to the server to handle and respond back to the client. The client then presents the response to the user. The user is therefore enabled to begin editing seamlessly as soon as the downloading is initiated, transparent to the fact that the entire file has not downloaded yet when the editing begins.
As editing of the file is in progress, the client sends the modified portions of the file to the server. The client sends the modified portions when the user selects to save the file wherein the server updates the file to include the modified portions. The modified portions are also sent by the client as the bandwidth on a connection between the client and the server becomes available. When the modified portions are sent based on the bandwidth availability, the server updates the file to include the modified portions only when a save command is received from the client.
This feature of sending modified portions when the bandwidth becomes available optimizes the network usage as well as improving performance. For example, if a user decides to save the file being edited by entering a xe2x80x9csavexe2x80x9d edit command when the network is tied up, the transfer of the modified file to the server must wait until the network is free to perform the transfer. The client process performing the save task may also be held up waiting for a reply from the server, creating a bottleneck. On the other hand, if the modified files were sent previously based on the network bandwidth availability, the file need not be transferred at the time of user""s save command, eliminating a need to wait for the network to be free.
For subsequent edits of the same file, the client and server cooperate to download only those portions of the file which have been changed since the last time the file was downloaded to the client. This feature of downloading only the necessary portions of the file enables additional performance improvement as well as freeing the bandwidth of the communications connection for other usage by minimizing the amount of data sent over the network.
The features and advantages of the present invention are provided by having a client residing at a user platform including a workstation or a personal computer (PC) and a server residing with a remote computer. The files for editing are typically located with the server or near the server. The files however need not physically reside on a same system as the server. For example, the file may be resident on a system which is connected to and accessible by the server via a network. The client includes a file buffer to hold the file downloaded from the server and a display buffer for holding the contents of the file buffer which are displayed on a display terminal at the client platform.
In accordance with the present invention, when an edit feature is invoked initially, the client spawns a thread to communicate to the server to download a file and to receive the downloaded file into the file buffer. At the same time, the client spawns a second thread to transfer the contents of the file buffer into the display buffer and to present a page of the file on the display terminal. The user at the client platform then may start editing the file even as the remaining portions of the file continue to download from the server into the file buffer.
When the user attempts to edit portions of the file which have not yet been downloaded, the client spawns an additional thread to send this edit request to the server, where the editing may be performed. The additional thread waits for the response from the server and when received presents the results to the user.
Generally, thereafter, the client spawns a thread for each editing request to enable more than one editing request to be processed at one time. For example, if two editing requests, first to xe2x80x9csavexe2x80x9d and second to xe2x80x9cgo to a selected pagexe2x80x9d were requested, a first thread is created and performs the save function while the second thread created displays the selected page on the display terminal. If these two editing requests were entered within a short period of time or almost at the same time, the two threads would perform their respective tasks simultaneously. The user, thus need not wait until the first task is completed before the second task is attempted.
The server typically resides at a remote computer and is a daemon process waiting or listening for editing requests from the client. When an edit request is received, the server spawns a first server thread to handle the request. The server then returns to its listening mode for additional requests. While the first thread is downloading a file to the client, a second thread may be created to handle an editing request from the client, the editing request associated with portions of file which are not yet downloaded. The second thread performs the task associated with the editing request directly at the server and returns the response to the client. Generally, the server spawns a thread for each request received to enable multi-tasking functionality.
Further features and advantages of the present invention as well as the structure and operation of various embodiments of the present invention are described in detail below with reference to the accompanying drawings. In the drawings, like reference numbers indicate identical or functionally similar elements.